Connectivity management between FIX clients and FIX Engine servers is static, operationally complex, time consuming and error prone. Financial organizations that offer FIX services statically assign unique TCP/IP endpoint identifiers to each client firm for connecting to and accessing FIX applications. These connection identifiers and the associated client information are maintained in a static and manually operated database. Changes to the network and/or the FIX server farm that impact the TCP/IP connection endpoints used for FIX connectivity will require a complex and time consuming process to implement the changes on the server and the client. Both firms need to collaborate on the changes to their network and security installations to ensure connectivity without negatively impacting network operations. Even simple modifications to TCP/IP connection endpoints require new security clearances and firewall configuration changes, which could take weeks before implementation.

FIX protocol was designed to automate exchange of trade information for real-time execution. But, ironically, FIX implementations use static and manually intensive process for FIX connectivity. Static connectivity management results in increased costs and lost profits due to 1) downtime caused by human errors, 2) lost revenue opportunity due to lengthy service turn-up, 3) service impacting network and server farm changes, and 4) lost business due to poor service and response time. Figure 1 below shows the static mapping of clients to FIX server farms, and highlights the lack of flexibility to make network and server farm changes.

Current FIX implementations only allow static failover to a redundant data center by configuring the FIX clients with a backup FIX server IP address. Clients connect to the alternate site when connectivity to the primary site fails. Using such client-enforced failover to a disaster recovery site is neither reliable nor consistent. Any failure in connectivity between the client and its corresponding servers will result in the client failing over to the alternate location, and not all clients will consistently failover. To ensure consistent application performance and client service, the FIX application provider must implement rapid, automatic and transparent disaster recovery that operates independent of the clients, and is truly based on the network and application state.

Brocade ServerIron FIXSWITCH helps create and manage virtual FIX application server farms, which completely decouple client connectivity management from internal network and server farm management. FIX application providers simply need to expose a single virtual IP address to all external clients to connect to the FIX servers. This virtual IP address is logically bound to multiple real server addresses belonging to redundant pairs of FIX servers. Client connection requests are first received by the ServerIron FIXSWITCH, which then identifies the client and re-directs the request to the corresponding pair of redundant FIX servers assigned to the specific client. Client identity may be based on a choice of Layer 3 (IP), Layer 4 (TCP Port) and Layer 7 (FIX header SenderCompID field) information. The ServerIron FIXSWITCH, with the intelligent application-aware load balancing and content switching capabilities, uniquely inspects deep into the FIX application messages to identify the FIX clients and send connection requests to the corresponding redundant FIX servers. Switching client connections to the servers based on FIX message content as opposed to the traditional TCP/IP information gives added flexibility, scalability, and security to the FIX application infrastructure. ServerIron FIXSWITCH supports both the “TAG=VALUE” and FIXML formats for inspecting FIX messages.

The Brocade patented Global Server Load Balancing (GSLB) solution allows geographic scalability and rapid disaster recovery for mission-critical FIX applications. Using the Brocade GSLB solution, financial firms can rapidly and automatically re-direct client connections to the backup data center during disastrous failures of the primary datacenter. Organizations can use GSLB to scale applications beyond one data center by geographically distributing and simultaneously utilizing multiple server farms. The ServerIron switches, with their intelligent GSLB controller function, direct client connections to different sites using many sophisticated site selection algorithms, starting with the static mapping of client IP addresses to a site to the most advanced round trip time based site selection. The failure of one or more sites does not impact the overall application availability. Client requests are automatically sent to other available sites.

• Data Sheets

  • Brocade ServerIron ADX Series 1000, 4000, and 10000 Switches (2.7 MB)