How I did it - "High-Performance S3 Load Balancing of Dell ObjectScale with F5 BIG-IP"

Introduction

As AI and data-driven applications continue to evolve, enterprises require storage solutions that can scale seamlessly while delivering high performance and resilience. Dell ObjectScale meets these demands with a cloud-native, S3-compatible architecture ideal for modern workloads like AI/ML and analytics. To further enhance ObjectScale’s capabilities, F5 BIG-IP LTM and F5 BIG-IP DNS provide intelligent traffic management and global load balancing—ensuring consistent performance, availability, and scalability across distributed environments. In this installment of "How I Did It," I introduce Dell ObjectScale and explore how F5 solutions integrate to support these advanced use cases.

Dell ObjectScale Overview

Dell ObjectScale is a modern, software-defined object storage platform designed to deliver cloud-native scalability and performance for enterprise environments. Built on a Kubernetes foundation, ObjectScale enables organizations to deploy S3-compatible object storage across on-premises, edge, and hybrid cloud infrastructures. Its native support for the Amazon S3 protocol allows seamless integration with a wide range of applications and tools that rely on S3 APIs for object storage operations such as PUT, GET, DELETE, and LIST. This compatibility ensures that developers and IT teams can leverage existing S3-based workflows without modification. They can benefit from ObjectScale’s enterprise-grade features like multi-tenancy, strong consistency, and integrated security. With its focus on simplicity, elasticity, and API-driven management, Dell ObjectScale is well-suited for modern workloads including AI/ML, analytics, backup, and cloud-native application development.

Integrating F5 BIG-IP for Scalable, Resilient Object Storage

F5 BIG-IP LTM and DNS provide a powerful load balancing solution that enhances Dell ObjectScale’s object storage platform by ensuring scalability, high availability, and performance. As ObjectScale is designed to support S3-compatible workloads across on-premises, edge, and hybrid cloud environments, F5 BIG-IP LTM intelligently distributes incoming S3 API traffic—such as PUT, GET, DELETE, and LIST—across multiple ObjectScale nodes or clusters. This ensures that workloads are balanced based on real-time metrics like connection count or server health, enabling seamless horizontal scaling as demand grows.

In parallel, BIG-IP DNS (formerly GTM) adds global server load balancing capabilities. It directs client requests to the most optimal ObjectScale deployment based on geolocation, latency, and availability. This is especially valuable in hybrid or multi-site deployments, where traffic needs to be routed intelligently across regions. Together, LTM and DNS provide continuous health monitoring and automatic failover, ensuring that object storage services remain accessible even during node or site failures.

Performance is further optimized through features like SSL offloading, TCP connection reuse, and DNS caching, all of which help reduce latency and improve throughput for high-volume S3 operations.

F5 BIG-IP platforms—ranging from Virtual Editions (VE) to high-performance rSeries and VELOS appliances—offer flexible deployment options to meet a wide range of performance and scalability needs. FastL4 virtual servers, optimized for Layer 4 processing, can deliver up to 800 Gbps of throughput and support over 100 million concurrent connections on fully loaded rSeries or VELOS systems. This makes them ideal for stateless, high-throughput S3 traffic.

For deployments that require TLS termination and Layer 7 visibility, both the F5 r10900 and the VELOS BX520 blade offer strong performance, but with different strengths. The r10900 can handle approximately 1.2 million Layer 7 requests per second (RPS), support up to 180 million concurrent TLS connections, and deliver around 140,000 SSL transactions per second (TPS). In contrast, a single VELOS BX520 blade significantly scales up Layer 7 performance, supporting around 15 million RPS and up to 400 million concurrent TLS connections, with SSL TPS around 110,000. These differences highlight how architectural factors like CPU frequency, vCPU density, and hardware acceleration influence real-world performance across platforms.

Virtual Editions also benefit from modern CPU advancements, with internal benchmarks showing 40–60% gains in HTTP performance when moving to newer processor generations. These performance tiers allow organizations to align BIG-IP deployment models with their specific workload and infrastructure goals.

This makes the combined F5 and Dell ObjectScale solution ideal for AI/ML, analytics, backup, and cloud-native applications. These applications need consistent, high-speed access to object storage. The remainder of this document outlines the configuration steps required to deploy F5 BIG-IP LTM and DNS for load-balancing Dell ObjectScale environments, ensuring optimal scalability, availability, and performance.

Load Balancing the ObjectScale VDC with F5 BIG-IP LTM

S3 Addressing in Dell ObjectScale

ObjectScale supports S3-compatible RESTful APIs for object access, including standard HTTP methods such as GET, PUT, POST, DELETE, and HEAD. Key aspects of S3 addressing in ObjectScale include:

Bucket-based addressing: ObjectScale supports both path-style and virtual-host-style bucket addressing, depending on client configuration and DNS setup.
Port configuration: S3 communication typically occurs over port 9020 (HTTP) or 9021 (HTTPS), as defined in the ObjectScale Security Configuration Guide.
Multi-protocol interoperability: Data ingested via S3 can be accessed through other supported protocols like NFS and Swift, though with some limitations due to protocol semantics.
Metadata search: ObjectScale enhances S3 functionality with rich metadata indexing and search capabilities, allowing clients to query objects using custom or system metadata fields.

TLS Termination…or NOT?

F5 BIG-IP offers two primary virtual server types for handling S3 traffic: FastL4 (Performance Layer 4) and Standard (Full Proxy) virtual servers. Each serves different performance and feature needs.

FastL4 Virtual Server: This option is optimized for high-throughput, low-latency traffic. It operates at Layer 4 (TCP/UDP) and uses the FastL4 profile to accelerate packet processing, often leveraging hardware like the ePVA chip when available. FastL4 is ideal for environments where raw performance is critical and minimal inspection or modification of traffic is required. However, it offers limited support for Layer 7 features and TLS termination. If TLS encryption is required, TLS termination will be performed on the ObjectScale node.
Standard Virtual Server: This full proxy option supports advanced Layer 7 features, including TLS termination, HTTP profile customization, and iRules for traffic manipulation. It allows the BIG-IP system to decrypt incoming HTTPS traffic, inspect or modify it before forwarding to backend ObjectScale nodes. While slightly more resource-intensive, it provides greater flexibility and visibility—important for environments requiring detailed traffic control or security inspection.

Note: Although it can be CPU-intensive, terminating a client connection twice—once on the BIG-IP LTM and again on the ObjectScale node—may be necessary when full end-to-end encryption is required and the LTM needs to inspect HTTP headers. This is often the case when using an iRule, (described in a later section) to hash an object’s name to determine the appropriate destination pool. In such scenarios, the LTM must decrypt the traffic to access the HTTP layer, then re-encrypt it before forwarding to ObjectScale. This ensures both security and intelligent traffic steering.

In S3 load balancing scenarios, FastL4 is typically used when performance is paramount and TLS termination is handled elsewhere or is not needed. Standard virtual servers are preferred when TLS offloading, application-layer visibility, or advanced traffic policies are required.

Note: For the remainder of this document, it is assumed that the reader has a general understanding of F5 BIG-IP and is familiar with configuring basic services. Foundational setup and introductory concepts are not covered. Refer to the BIG-IP LTM-DNS operations guide for additional information and guidance related to F5 BIG-IP LTM/DNS.

Speed it up with Performance (FastL4) and TLS passthrough

FastL4 is ideal for high-performance environments with minimal traffic inspection. It does not support Layer 7 features or TLS termination, which must instead occur on the ObjectScale node if encryption is required. To enable FastL4 S3 load balancing, you will configure the following BIG-IP resources:

Custom S3 Health Monitor
ObjectScale Pool(s)
Performance (FastL4) virtual server

Create a custom S3 Health Monitor

Log in to the BIG-IP Configuration Utility and navigate to Local Traffic > Monitors.
Click Create.
1. Enter a Name for your monitor (e.g., objectscale-s3-ping-9021).
2. Set the Type to HTTPS.
Configure Basic Settings (see below)
1. Send String: The HTTP request to send (GET /?ping HTTP/1.1\r\nHost:f5\r\n\r\n). Use of the S3 Ping operation is recommended in monitoring ECS S3 service port availability on ECS software running on dedicated ECS hardware. This operation is documented inside the Dell EMC ECS REST API Reference Guide, which can be found at https://www.emc.com/techpubs/api/ecs/v3-0-0-0/index.htm.
2. Receive String: The expected response (<Name>MAINTENANCE_MODE</Name><Status>OFF</Status>).

4. Select ‘Finished’ to create the monitor (see above).

Create Dell ObjectScale pool

If necessary, log in to the BIG-IP Configuration Utility and navigate to Local Traffic > Pools.
Click Create.

Enter a Name (e.g., objectscale_vdc1).
Assign the previously created Health Monitor (e.g., objectscale-s3-ping-9021).
Choose a Load Balancing Method (Least Connections is the recommended method for ObjectScale VDC nodes).
Add Pool Members. For each ObjectSale node, provide a name, address, and port (9021).

3. Select ‘Finished’ to create the pool (see above).

Create Performance (FastL4) virtual server

If necessary, log in to the BIG-IP Configuration Utility and navigate to Local Traffic > Virtual Servers.
Click Create.

Enter a Name (e.g., objectscale_vs_fastL4).
Type: Select Performance (Layer4) — this enables FastL4 processing.
Destination Address/Mask: Enter the IP address clients will connect to.
Service Port: Enter the port number ( 443 for HTTPS passthrough).
Source Address Translation: Set to Automap
Default Pool: Select the previously created ObjectScale pool (e.g., objectscale_vdc1).
SNAT: Set to Automap or specify a SNAT pool if needed.
Default Persistence Profile: Optionally, select source_addr.

3. Select ‘Finished’ to create the virtual server (see above).

ObjectScale Storage Efficiency

Dell ObjectScale uses XOR-based encoding as part of its erasure coding strategy to optimize storage efficiency and resilience during S3 read/write operations, particularly in multi-site deployments.

When ObjectScale is set up with a replication group that includes three or more sites, it uses XOR encoding to save storage space while keeping data safe. Each site in the replication group maintains a chunk manager table that tracks data chunks and their roles (e.g., primary, copy, remote). When a site finds that it has many copy-type chunks from other sites, it can do an XOR on those chunks to make a parity chunk locally.

For example, if Site 3 holds two copy chunks—C2 from Site 2 and C3 from Site 1—it can compute a new chunk C5 as the XOR of C2 and C3. This new chunk is marked as a parity chunk and stored locally. Once the XOR operation is complete, the original copy chunks (C2 and C3) are deleted, and their entries in the chunk manager table are updated to reflect that they are now encoded.

Impact on S3 Read/Write Operations

Write Efficiency: During writes, ObjectScale distributes data across sites and uses XOR encoding to reduce the number of full data copies needed, saving disk space and improving write throughput.
Read Optimization: For reads, ObjectScale prioritizes serving data from the primary site. If a primary chunk is unavailable, the system can reconstruct the data using the XOR parity chunk and the remaining copy.
Storage Savings: This approach significantly reduces the storage footprint compared to full replication, especially as the number of sites increases.
Transparency to S3 Clients: All of this is abstracted from the S3 client. Applications using the S3 API interact with ObjectScale as if it were a standard S3-compatible object store, while the platform handles encoding and decoding behind the scenes.
This XOR-based erasure coding model lets ObjectScale provide high availability and fault tolerance with less storage work, making it good for large-scale S3 workloads.

There’s an iRule for that!

Some organizations may benefit from configuring BIG-IP LTM to access both local and remote ObjectScale nodes. While applications perform best when communicating with a local ObjectScale site, those that can tolerate added latency may take advantage of ObjectScale’s XOR-based storage efficiency, which requires data to be written evenly across three or more sites.

However, reading data from remote sites can introduce WAN overhead and caching inefficiencies. This is because ObjectScale maintains strong consistency by assigning object ownership to a specific VDC. When an object is read from a non-owner site, ObjectScale must verify the latest version with the owner across the WAN.

To reduce this overhead, LTM can direct read requests to the site where the object was originally written, minimizing WAN traffic and avoiding unnecessary caching. This improves performance and ensures efficient use of ObjectScale resources.

While round-robin write distribution maximizes XOR efficiency, applying the same logic to reads can lead to performance issues. Instead, a geo-affinity algorithm—validated using the S3 API—ensures writes are balanced across sites while reads are directed to the original write location. This approach reduces WAN traffic, improves performance, and eliminates the need to cache remote data.

The example iRule below uses a hash of the object path to consistently route requests to the correct pool, with one local and two remote ObjectScale sites configured.

when HTTP_REQUEST { 

    set mybaseURL "s3.global.f5demo.net"
    if { [HTTP::path] ne {/} and [HTTP::path] starts_with {/} }{ if { [getfield [HTTP::host] {:} 1] ends_with $mybaseURL or  [getfield [HTTP::host] {:} 1] ends_with ".s3.amazonaws.com" }{ set path [string range [HTTP::path] 1 end] } 
else { 
set pathList [split [HTTP::path] {/}] 

if { [llength $pathList] > 2  } { 
    set path [string range [join [replace $pathList 1 1] {/}] 1 end] 
    } 
} 
if { [info exists path] and $path ne {} } { binary scan [sha1  $path] H6 hash 
switch -- [expr 0x$hash % 3 ] { 
0 { pool /Common/objectscale_vdc1 } 
1 { pool /Common/objectscale_vdc2 } 
2 { pool /Common/objectscale_vdc3 } 
} 
} 
} 
}

Reducing backend load and with a Standard Virtual Server and TLS termination

The Standard virtual server type enables advanced Layer 7 features such as TLS termination, HTTP profile customization, and iRules for traffic control. Backend ObjectScale nodes can receive traffic unencrypted (as shown below) or re-encrypted when end-to-end TLS is required.

Note: For remote backend pools—including when using the above-noted geo-affinity iRule—TLS re-encryption is strongly recommended.

To enable S3 load balancing utilizing a Standard virtual server, you will configure the following BIG-IP resources:

Custom S3 Health Monitor
ObjectScale Pool(s)
Geo-Affinity iRule, (as described in previous section)
Standard virtual server

Create a custom S3 Health Monitor

Log in to the BIG-IP Configuration Utility and navigate to Local Traffic > Monitors.
Click Create.
1. Enter a Name for your monitor (e.g., objectscale-s3-ping-9020).
2. Set the Type to HTTP.
3. Send String: The HTTP request to send (GET /?ping HTTP/1.1\r\nHost:f5\r\n\r\n). Use of the S3 Ping operation is recommended for monitoring ECS S3 service port availability on ECS software running on dedicated ECS hardware. This operation is documented inside the Dell EMC ECS REST API Reference Guide, which can be found at https://www.emc.com/techpubs/api/ecs/v3-0-0-0/index.htm.
4. Receive String: The expected response (<Name>MAINTENANCE_MODE</Name><Status>OFF</Status>).

3. Select ‘Finished’ to create the monitor (see above).

Create Dell ObjectScale pool (utilizing TLS offload)

If necessary, log in to the BIG-IP Configuration Utility and navigate to Local Traffic > Pools.
Click Create.
1. Enter a Name (e.g., objectscale_vdc1_9020).
2. Assign the previously created Health Monitor (e.g., objectscale-s3-ping-9020).
3. Choose a Load Balancing Method (Least Connections is the recommended method for ObjectScale VDC nodes).
4. Add Pool Members. For each ObjectSale node, provide a name, address, and port (9020).

3. Select ‘Finished’ to create the pool (see above).

Create Standard virtual server

If necessary, log in to the BIG-IP Configuration Utility and navigate to Local Traffic > Virtual Servers.
Click Create.

Enter a Name (e.g., objectscale_vs_standard).
Type: Select Standard.
Destination Address/Mask: Enter the IP address clients will connect to.
Service Port: Enter the port number ( 443 for HTTPS).
HTTP Profile (Client): Select http.
SSL Profile (Client): Select a previously created Client SSL profile corresponding to a previously uploaded/created TLS certificate/key combination.
SSL Profile (Server): (Optional) If TLS re-encryption to the backend pool is required, select services from the available options.

1. Source Address Translation: Set to Automap
2. OneConnect Profile: To enable connection reuse between clients and servers, select the default profile, oneconnect.
3. iRules: For multi-VDC connectivity, create and select the previously described iRule.
4. Default Pool: Select the previously created ObjectScale pool (e.g., objectscale_vdc1_9020).
5. Default Persistence Profile: Optionally, select source_addr.

3. Select ‘Finished’ to create the virtual server (see above).

Efficient Load Balancing across Multiple ObjectScale Sites with F5 BIGIP DNS

BIG-IP DNS enables intelligent load balancing across multiple Dell ObjectScale VDC sites within a replication group by directing client requests to the optimal site based on proximity, health, or custom logic. This ensures high availability and performance for S3 workloads, even in geographically distributed deployments. When paired with geo-affinity iRules, BIG-IP DNS can dynamically steer traffic to the nearest or healthiest VDC. This improves latency and resiliency while optimizing read/write operations. For additional configuration details, refer to the BIG-IP DNS/DNS services operations guide.

Configure DNS Listeners

A BIG-IP DNS listener is a virtual server that listens for DNS queries on a specified IP address and port (typically UDP/TCP 53), enabling the BIG-IP system to process and respond to DNS requests for services like GSLB.

If necessary, log in to the BIG-IP Configuration Utility and navigate to DNS > Delivery > Listeners > Listener List.
Click Create.
Configure Basic Settings
1. Enter a Name: Enter a descriptive name (e.g., DNS_TCP_listener).
2. Destination Address/Mask: Enter the IP address the BIG-IP will receive DNS requests.
3. Select the appropriate protocol (TCP or UDP).

4. Click ‘Finished’ to create the listener.

5. Repeat steps 1-4 to create a UDP listener.

Define Data Centers

BIG-IP DNS data centers are logical groupings that represent physical or cloud locations used in GSLB to route DNS traffic based on health, geography, and performance. They enable intelligent traffic distribution and high availability across globally distributed applications.

If necessary, log in to the BIG-IP Configuration Utility and navigate to DNS > GSLB > Data Centers.
Click Create.
Configure Basic Settings
1. Enter a Name: Enter a descriptive name (e.g., DC1).
2. Location: Provide a descriptive location for the data center (e.g., Seattle).
3. Select the appropriate Prober preference (defaults to Inside Data Center).

4. Click ‘Finished’ to create the data center.

5. Repeat steps 1-4 to create additional data centers as necessary.

Configure and associate BIG-IP DNS servers with Data Centers

BIG-IP DNS server objects represent physical or virtual DNS servers within a data center. They are used to monitor and route DNS traffic based on health, performance, and proximity.

If necessary, log in to the BIG-IP Configuration Utility and navigate to DNS > GSLB > Servers > Server List.
Click Create.
Configure Basic Settings.

1. Enter a Name: Enter a name for the server (e.g., bigip1.f5demo.net).
2. Data Center: Select the data center where the server resides.
3. BIG-IP System Devices: Click on ‘Add’ and provide the BIG-IP’s
4. Health Monitor: Select ‘bigip’.
5. Virtual Server Discovery: Select ‘Enabled’ to automatically detect and associate virtual servers on defined BIG-IP system(s).

4. Click ‘Finished’ to create the data center.

5. Repeat steps 1-4 to create define additional servers as necessary.

Create the GSLB Pool

The GSLB pool in BIG-IP DNS is a collection of virtual servers across multiple data centers that distribute DNS traffic based on health, performance, and proximity to ensure high availability and optimal user experience.

If necessary, log in to the BIG-IP Configuration Utility and navigate to DNS > GSLB > Pools > Pool List.
Click Create.
Configure Basic Settings
1. Enter a Name: Provide a name for the pool (e.g., objectscale_standard_pool).
2. Type: Select ‘A’. The pool/wide IP responds to A queries.
3. Health Monitors: Select ‘https’.
4. Load Balancing Method: Select ‘Topology’ for the preferred method. The topology GSLB method in BIG-IP DNS directs client requests based on the geographic location of the client's DNS resolver, ensuring users are routed to the closest or most appropriate datacenter for optimal performance.
5. Member List: Select the appropriate virtual servers (automatically discovered) from the list and click on ‘Add’.

4. Click ‘Finished’ to create the pool.

Create GSLB Wide IP

A GSLB Wide IP in BIG-IP DNS is a globally resolvable DNS name that maps to one or more pools of application resources. It acts as the entry point for distributing client requests across multiple data centers based on load balancing methods like topology, availability, or performance.

If necessary, log in to the BIG-IP Configuration Utility and navigate to DNS > GSLB > Wide IPs > Wide IP List.
Click Create.
Configure Basic Settings
1. Under General Properties, select ‘Advanced’.
2. Enter a Name the FQDN clients will query, (e.g. s3.global.f5demo.net). The entry corresponds to the ObjectScale DefaultBaseURL and iRule referenced in a previous section.
3. Type: Select ‘A’ record type.
4. Alias List: Add any necessary alias DNS records. In the example provided (see below), a wildcard alias, (*.s3.global.f5demo.net) has been added. The wildcard alias enables virtual-host-style bucket addressing, (e.g. bucket1.s3.global.f5demo.net, bucket5.s3.global.f5demo.net, etc.).
5. Load Balancing Method: Select ‘Topology’.
6. Pool List: From the list of pools select the previously created GSLB pool and click on ‘Add’.